Key management method used in encryption processing for safely transmitting and receiving messages

ABSTRACT

A key management method serves as an electronic control unit (ECU) in an onboard network system having a plurality of ECUs that perform communication by frames via a network. The method includes storing a shared key and executing encryption processing based on the shared key. The method further includes executing inspection of a security state of the shared key stored in a case where a vehicle is in at least one of the following particular states: the vehicle is not driving and is an accessory-on state; a fuel cap of the vehicle is open, and the vehicle is not driving and is fueling; the vehicle is parked, which is indicated by the gearshift; the vehicle is in a stopped state before driving, which is indicated by the gearshift; and a charging plug is connected to the vehicle, and the vehicle is electrically charging.

CROSS REFERENCE TO RELATED APPLICATIONS

This is a continuation application of U.S. patent application Ser. No.16/686,855, filed Nov. 18, 2019, which is a continuation application ofU.S. patent application Ser. No. 15/203,622, filed Jul. 6, 2016, nowU.S. Pat. No. 10,530,572, issued Jan. 7, 2020, which is a continuationapplication of International Patent Appl. No. PCT/JP2015/005223, filedOct. 16, 2015, which claims the benefit of U.S. Provisional Patent Appl.No. 62/079,301, filed Nov. 13, 2014, and priority to Japanese PatentAppl. No. 2015-168311, filed Aug. 27, 2015. The disclosure of each ofthe above-identified documents, including the specification, drawings,and claims, is incorporated herein by reference in its entirety.

1. TECHNICAL FIELD

The present disclosure relates to key management technology used inencryption processing for safely transmitting and receiving messages(frames) over an onboard network.

2. DESCRIPTION OF THE RELATED ART

In recent years, a great number of electronic control units (ECU) havebeen placed in systems in automobiles. A network connecting these ECUsis referred to as an onboard network. Many standards exist for onboardnetworks. The most mainstream of these is a standard called ControllerArea Network (CAN), that is stipulated in ISO11898-1 (see CANSpecification 2.0 Part A, [online], CAN in Automation (CiA), [searchedNov. 14, 2014], Internet (URL:http://www.can-cia.org/fileadmin/cia/specifications/CAN20A.pdf)).

A CAN is configured using two busses, and each ECU connected to thebuses is called a node. Each node connected to a bus transmits/receivesmessages called frames. No identifiers indicating the transmissiondestination or transmission source exist in CAN, with the transmittingnode attaching an ID (called CAN-ID) to each frame and transmitting(i.e., sending out signals to the bus), and the receiving nodes onlyreceiving frames of a predetermined ID (i.e., reading signals from thebus). The Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA)format is employed, so when multiple nodes transmit at the same time,arbitration by CAN-ID is performed, with frames having a smaller messageID value being transmitted with higher priority.

Now, CAN does not have a security function assuming a case whereunauthorized frames are transmitted, so there is a possibility that thevehicle might be unauthorizedly controlled by an unauthorized node beingconnected to the bus in the onboard network and the unauthorized frameunauthorizedly transmitting a frame. There is known a technology in CANwhere frames transmitted by authorized ECUs are identified by adding amessage authentication code (MAC) to the data field and transmitting, inorder to prevent control by such unauthorized frames (see JapaneseUnexamined Patent Application Publication No. 2013-98719). A temporarysession key is preferably periodically generated and used in generatingMACs, to improve resistance against brute-force attacks against MACs totry to identify the key to generate MACs.

Now, in a case where a particular ECU handles generating of a sessionkey, the session key can be safely distributed (transmitted) among ECUsif the session keys are encrypted using a key shared among authorizedECUs beforehand (called a “shared key”). However, if leakage of theshared key cannot be appropriately detected, this enables anunauthorized ECU to receive the session key and generate MACs.

SUMMARY

One non-limiting and exemplary embodiment provides a key managementmethod for securing security of an onboard network having multiple ECUsstoring a shared key. The present disclosure also provides an onboardnetwork system and key management device for securing security incommunication among ECUs storing a shared key.

In one general aspect, the techniques disclosed here feature a keymanagement method in an onboard network system having a plurality ofelectronic control units that perform communication by frames via a bus,the method including:

storing, in a first-type electronic control unit out of the plurality ofelectronic control units, a shared key to be mutually shared with one ormore second-type electronic control units other than the first-typeelectronic control unit, the shared key also being stored in the one ormore second-type electronic control units other than the first-typeelectronic control unit;

acquiring, by each of the second-type electronic control units, asession key by communication with the first-type electronic control unitbased on the stored shared key, and after this acquisition, executingencryption processing regarding a frame transmitted or received via thebus, using this session key; and

executing, by the first-type electronic control unit, inspection of asecurity state of the shared key stored by the second-type electroniccontrol units in a case where a vehicle in which the onboard networksystem is installed is in a particular state.

According to the present disclosure, the security state of the sharedkey is inspected on a timely basis, so security of the onboard networksystem can be secured.

It should be noted that general or specific embodiments may beimplemented as a system, a method, an integrated circuit, a computerprogram, a storage medium, or any selective combination thereof.

Additional benefits and advantages of the disclosed embodiments willbecome apparent from the specification and drawings. The benefits and/oradvantages may be individually obtained by the various embodiments andfeatures of the specification and drawings, which need not all beprovided in order to obtain one or more of such benefits and/oradvantages.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating the overall configuration of an onboardnetwork system according to a first embodiment;

FIG. 2 is a diagram illustrating the format of a data frame stipulatedby the CAN protocol;

FIG. 3 is a configuration diagram of a master ECU (key managing device)according to the first embodiment;

FIG. 4 is a diagram illustrating an example of a reception ID list thatthe master ECU (key managing device) stores;

FIG. 5 is a diagram illustrating an example of a shared key list thatthe master ECU (key managing device) stores, according to the firstembodiment;

FIG. 6 is a diagram illustrating an example of a session key list thatthe master ECU (key managing device) stores;

FIG. 7 is a configuration diagram of an ECU according to the firstembodiment;

FIG. 8 is a diagram illustrating an example of a reception ID list thatthe ECU stores;

FIG. 9 is a diagram illustrating an example of a reception ID list thatthe ECU stores;

FIG. 10 is a diagram illustrating an example of CAN-IDs and data fieldsin frames transmitted from an ECU connected to an engine;

FIG. 11 is a diagram illustrating an example of CAN-IDs and data fieldsin frames transmitted from an ECU connected to the brakes;

FIG. 12 is a diagram illustrating an example of CAN-IDs and data fieldsin frames transmitted from an ECU connected to a door open/close sensor;

FIG. 13 is a diagram illustrating an example of CAN-IDs and data fieldsin frames transmitted from an ECU connected to a window open/closesensor;

FIG. 14 is a diagram illustrating an example of a shared key that isstored by ECUs;

FIG. 15 is a diagram illustrating an example of a session keydistribution sequence between the master ECU (key managing device) andECUs;

FIG. 16 is a diagram illustrating an example of a message authenticationsequence among ECUs;

FIG. 17 is a diagram illustrating an example of a shared keyverification sequence between the master ECU (key managing device)according to the first embodiment and ECUs;

FIG. 18 is a configuration diagram of a master ECU (key managing device)according to the first embodiment;

FIG. 19 is a diagram illustrating an example of a shared keyverification sequence between the master ECU (key managing device)according to a modification of the first embodiment and ECUs;

FIG. 20 is a configuration diagram of a master ECU (key managing device)according to a second embodiment;

FIG. 21 is a diagram illustrating an example of a shared key list thatthe master ECU (key managing device) according to the second embodimentstores;

FIG. 22 is a configuration diagram of an ECU according to the secondembodiment;

FIG. 23 is a diagram illustrating an example of a shared keyverification sequence between the master ECU (key managing device)according to the second embodiment and ECUs;

FIG. 24 is a configuration diagram of a master ECU (key managing device)according to a modification of the second embodiment;

FIG. 25 is a diagram illustrating an example of a shared keyverification sequence between the master ECU (key managing device)according to the modification of the second embodiment and ECUs;

FIG. 26 is a configuration diagram of a master ECU (key managing device)according to a third embodiment;

FIG. 27 is a diagram illustrating an example of a sequence recordinglist according to the third embodiment;

FIG. 28 is a diagram illustrating an example of a shared keyverification sequence between the master ECU (key managing device)according to the third embodiment and ECUs;

FIG. 29 is a configuration diagram of a master ECU (key managing device)according to a modification of the third embodiment; and

FIG. 30 is a diagram illustrating an example of a shared keyverification sequence between the master ECU (key managing device)according to the modification of the third embodiment and ECUs.

DETAILED DESCRIPTION

A key management method according to an aspect of the present disclosureis a key management method in an onboard network system having aplurality of electronic control units that perform communication byframes via a bus. The method includes: storing, in a first-typeelectronic control unit out of the plurality of electronic controlunits, a shared key to be mutually shared with one or more second-typeelectronic control units other than the first-type electronic controlunit, the shared key also being stored in the one or more second-typeelectronic control units other than the first-type electronic controlunit; acquiring, by each of the second-type electronic control units, asession key by communication with the first-type electronic control unitbased on the stored shared key, and after this acquisition, executingencryption processing regarding a frame transmitted or received via thebus, using this session key; and executing, by the first-type electroniccontrol unit, inspection of a security state of the shared key stored bythe second-type electronic control units in a case where a vehicle inwhich the onboard network system is installed is in a particular state.

The inspection may be an inspection relating to an expiration date ofthe shared key. Accordingly, expiration of the shared key can bedetected, and acquisition of session keys by an unauthorized ECU havingan expired shared key can be prevented.

The first-type electronic control unit may receive, from the second-typeelectronic control unit, a frame including information indicating theexpiration date regarding the shared key that the second-type electroniccontrol unit holds, perform the inspection by distinguishing whether ornot the expiration date has already expired, an in a case where theexpiration date has not expired, perform communication to give thesecond-type electronic control unit a session key, but in a case wherethe expiration date has expired, execute control for notification.Accordingly, notification is made in a case where the security state ofthe shared key is inappropriate due to the existence of an ECU having anexpired shared key, so security can be secured.

The inspection may be an inspection relating to a serial ID of thesecond-type electronic control unit that stores the shared key.Accordingly, the existence of an unauthorized ECU that hasunauthorizedly copied (duplicated) the share key can be detected, andacquisition of a session key by the unauthorized ECU can be prevented.

The first-type electronic control unit may receive, from the second-typeelectronic control unit, a frame including information indicating theserial ID of the second-type electronic control unit, perform theinspection by distinguishing whether or not the security state of theshared key is appropriate based on the serial ID and predeterminedmatching information stored beforehand, and in a case where the securitystate of the shared key is appropriate, performs communication to givethe second-type electronic control unit a session key, but in a casewhere the security state of the shared key is not appropriate, executecontrol for notification. Accordingly, notification is made in a casewhere the security state of the shared key is inappropriate due to theexistence of the ECU having an unauthorized serial ID, so security canbe secured.

In a case where the plurality of electronic control units includes aplurality of the second-type electronic control units, the inspectionmay be an inspection relating to a transmission order of frames at theplurality of second-type electronic control units. Accordingly,inappropriate transmission order of frames among the ECUs can bedetected, and acquisition of a session key by an unauthorized ECU can beprevented.

The first-type electronic control unit may transmit a frame indicating apredetermined request and thereafter sequentially receive frames fromthe plurality of second-type electronic control units, and based on theIDs of the frames, perform the inspection by distinguishing whether ornot the IDs have been received in an order that a predetermined orderlist indicates. Accordingly, whether or not an unauthorized ECU existscan be detected from the order of responses from each ECU after havingtransmitted a frame (survival confirmation frame or the like) indicatinga predetermined request.

The particular state may be a state where the vehicle is not driving,with the first-type electronic control unit executing the inspectiononly in a case of the particular state. Accordingly, inspection of thesecurity state can be appropriately performed while avoiding increasedprocessing load on the ECUs increased traffic on the bus and so forthwhile the vehicle is driving.

The first-type electronic control unit may execute the inspection bycommunication with a server located externally from the vehicle.Accordingly, the load of the inspection of the security state within theonboard network system can be reduced. Also, inspections usinginformation collected externally from the vehicle (information obtainedfrom other onboard network systems and so forth) may also be performed.

The plurality of electronic control units may perform communication byframes via the bus, following a CAN protocol. Accordingly, security canbe secured in a onboard network system following CAN.

An onboard network system according to an aspect of the presentdisclosure is an onboard network system having a plurality of electroniccontrol units that perform communication by frames via a bus. Afirst-type electronic control unit out of the plurality of electroniccontrol units, stores a shared key to be mutually shared with one ormore second-type electronic control units other than the first-typeelectronic control unit, the shared key also being stored in the one ormore second-type electronic control units other than the first-typeelectronic control unit, each of the second-type electronic controlunits acquire a session key by communication with the first-typeelectronic control unit based on the stored shared key, and after thisacquisition, execute encryption processing regarding a frame transmittedor received via the bus, using this session key, and the first-typeelectronic control unit executes inspection of a security state of theshared key stored by the second-type electronic control units in a casewhere a vehicle in which itself is installed is in a particular state.Thus, security of the onboard network system can be secured.

A key management device according to an aspect of the present disclosureis a key management device serving as an electronic control unit in anonboard network system having a plurality of electronic control unitsthat perform communication by frames via a bus. The key managementdevice stores a shared key to be mutually shared with one or moreelectronic control units other than itself out of the plurality ofelectronic control units, for transmission of a session key used forencryption relating to a frame, the shared key also being stored in theone or more second-type electronic control units other than thefirst-type electronic control unit, and the key management deviceexecutes inspection of a security state of the shared key stored by theelectronic control units other than itself in a case where a vehicle inwhich itself is installed is in a particular state. Thus, security ofthe onboard network system can be secured.

These general or specific aspects may be realized by a system, method,integrated circuit, computer program, or computer-readable recordingmedium such as a CD-ROM, and may be realized by any combination of asystem, method, integrated circuit, computer program, and recordingmedium.

The following is a detailed description of an onboard network systemaccording to embodiments with reference to the drawings. Note that theembodiments described below are all specific examples of the presentdisclosure. Accordingly, values, components, placements and connectedstates of components, steps (processes) and the order of steps, and soforth illustrated in the following embodiments, are only exemplary, anddo not restrict the present disclosure. Components in the followingembodiments which are not included in an independent Claim are optionalcomponents. The drawings are all schematic diagrams and are notnecessarily created in an exact manner.

First Embodiment

A key management method used in an onboard network system 10 in whichmultiple ECUs including a master ECU (key managing device) 400communicate via a bus will be described below with reference to thedrawings. An example will be described in the present embodimentregarding a key management method, where whether or not the risk ofleaking of a shared key, which each ECU stores, has increased (i.e.,whether or not the state is one where updating of the shared key isnecessary) is determined (verified) regarding security, based on anexpiration data of the shared key, in accordance with the state of thevehicle.

1.1 Overall Configuration of Onboard Network System

FIG. 1 is a diagram illustrating the overall configuration of theonboard network system 10 according to a first embodiment. The onboardnetwork system 10 is an example of a network communication system thatcommunicates following the CAN protocol, and is a network communicationsystem in an automobile in which is installed various types of devicessuch as control devices, sensors, and so forth. The onboard networksystem 10 has multiple devices that communicate by frames via a busfollowing the CAN protocol, and uses a key management method.Specifically, the onboard network system 10 is configured including abus 200, the master ECU (key management device) 400, and nodes like ECUsconnected to the bus, such as ECUs 100 a through 100 d and so forth,that are connected to various types of devices, as illustrated inFIG. 1. The onboard network system 10 may include many more ECUs thanthe master ECU 400 and ECUs 100 a through 100 d, but description will bemade here focusing on the master ECU 400 and ECUs 100 a through 100 dfor sake of convenience. An ECU is a device that includes, for example,digital circuits such as a processor (microprocessor), memory, and soforth, analog circuits, communication circuits, and so forth. The memoryis read-only memory (ROM), random access memory (RAM), and so forth,capable of storing a control program (computer program) to be executedby the processor. The ECU can realize various functions by the processoroperating following the control program (computer program), for example.The computer program is configured as a combination of multiple commandcodes representing instructions to the processor, to achievepredetermined functions.

The ECUs 100 a through 100 d are connected to the bus 200, and areconnected to an engine 310, brakes 320, a door open/closed sensor 330,and a window opened/closed sensor 340, respectively. Each of the ECUs100 a through 100 d acquires the state of the device to which it isconnected (engine 310, etc.), and periodically transmits frames(later-described data frames) and so forth representing the state to thenetwork (i.e., the bus).

There is one master ECU 400 connected to the bus 200, as a type of ECUserving as a key managing device that has the role of handlingprocessing relating to keys used in exchanging frames among the ECUs.The master ECU 400 has the same shared key as one or more ECUs out ofthe multiple ECUs connected to the bus 200 besides itself, to use fortransmitting session keys mutually between the one or more ECUs forencryption processing relating to frames (including MAC processing), andfunctions to manage the security state of the shared key. The master ECU400 may record a log of the security state of the shared key in arecording medium such as memory, a hard disk, or the like, as necessary.The master ECU 400 may have a display device such as a liquid crystaldevice (LCD) or the like provided on an instrument panel or the like ofthe automobile, so as to notify the driver by displaying informationaccording to the security state of the shared key.

The ECUs on the onboard network system 10 including the master ECU 400exchange frames following the CAN protocol. Frames in the CAN protocolinclude data frames, remote frames overload frames, and error frames.Description will be made primarily here regarding data frames, for sakeof convenience.

1.2 Data Frame Format

The following is a description of a data frame which is a type of frameused on a network according to the CAN protocol. FIG. 2 is a diagramillustrating a format of a data frame stipulated by the CAN protocol.The diagram illustrates a data frame according to a standard ID formatstipulated in the CAN protocol. A data frame is configured including thefields of a Start Of Frame (SOF), ID field, Remote Transmission Request(RTR), Identifier Extension (IDE), reserved bit “r”, Data Length Code(DLC), data field, Cyclic Redundancy Check (CRC) sequence, CRC delimiter“DEL”, Acknowledgement (ACK) slot, ACK delimiter “DEL”, and End Of Frame(EOF).

The SOF is made up of 1-bit dominant. The state of the bus is recessivewhen idle, and start of transmission of a frame is notified by beingchanged to dominant by the SOF.

The ID field is made up of 11 bits, and is a field storing an ID(CAN-ID) which is a value indicating the type of data. Design has beenimplemented so that in a case where multiple nodes start transmission atthe same time, frames with smaller ID values are given higher priority,in order to perform communication arbitration using this ID field.

The RTR is a value identifying a data frame and remote frame, and ismade up of 1-bit dominant in a data frame.

The IDE and “r” are each made up of 1-bit dominant.

The DLC is made up of four bits, and is a value indicating the length ofthe data field. Note that the IDE, “r”, and DLC together are called acontrol field.

The data field is a maximum of 64 bits, and is a value indicating thecontent of the data being transmitted. The length can be adjusted in8-bit increments. The CAN protocol does not stipulate the specificationof data being transmitted; that is set at the onboard network system 10.Accordingly, the specification is dependent on the model, manufacturer(manufacturing maker), or the like.

The CRC sequence (“CRC” illustrated in FIG. 2) is made up of 15 bits.This is calculated from the transmitted values of the SOF, ID field,control field, and data field.

The CRC delimiter (the “DEL” between the “CRC” and “ACK” in FIG. 2) ismade up of 1-bit recessive, and is a sectioning symbol representing theend of the CRC sequence. The CRC sequence and CRC delimiter arecollectively referred to as the CRC field.

The ACK slot (the “ACK” in FIG. 2) is made up of one bit. Thetransmitting node performs transmission with the ACK slot set torecessive. The receiving node transmits the ACK slot as dominant if upto the CRC sequence has been received normally. Dominant has higherpriority than recessive, so if the ACK slot is dominance aftertransmission, so the transmitting node will be able to confirm that oneof the receiving nodes has succeeded in reception.

The ACK delimiter (the “DEL” between the “ACK” and “EOF” in FIG. 2) ismade up of 1-bit recessive, and is a sectioning symbol representing theend of the ACK.

The EOF is made up of 7-bits recessive, and represents the end of thedata frame.

1.3 Configuration of Master ECU 400

FIG. 3 is a configuration diagram of the master ECU 400. The master ECU400 includes a frame transmission/reception unit 401, a frame analyzingunit 402, a reception ID judging unit 403, a reception ID list storingunit 404, an expiration data confirming unit 405, a MAC processing unit406, a counter storing unit 407, a session key list storing unit 408, anencryption processing unit 409, a shared key list storing unit 410, asession key generating unit 411, and a frame generating unit 412. Thesecomponents are functional components, and the functions thereof arerealized by a communication circuit in the master ECU 400, a processoror digital circuit of the like that executes the program stored in thememory, and so forth.

The frame transmission/reception unit 401 transmits and receives framesfollowing the CAN protocol to and from the bus 200. Frames are receivedfrom the bus 200 one bit at a time, and transferred to the frameanalyzing unit 402. The contents of frames received from the framegenerating unit 412 are transmitted to the bus 200 one bit at a time.

The frame analyzing unit 402 receives the values of frames from theframe transmission/reception unit 401, and performs analysis so as tomap to the fields in the frame format stipulated in the CAN protocol.The frame analyzing unit 402 transfers a value determined to be an IDfield to the reception ID judging unit 403. The frame analyzing unit 402decides, in accordance with determination results notified from thereception ID judging unit 403, whether to transfer the value of an IDfield (CAN-ID) and a data field appearing after the ID field, to the MACprocessing unit 406, or to cancel reception of frames after havingreceived the determination results (i.e., to stop analyzing that frame).After transferring to the MAC processing unit 406, the processingresults at the MAC processing unit 406 (the MAC verification results)are received, and in a case of having been determined to be normal(i.e., in a case where MAC verification has been successful), the valueof the ID field and the data field appearing after the ID field arenotified to the expiration data confirming unit 405. In a case where theframe is judged not to be following the CAN protocol, such as the CRCvalue not matching, or an item fixed to dominant being recessive, theframe analyzing unit 402 notifies the frame generating unit 412 totransmit an error frame. In a case of having received an error frame,i.e., in a case of having analyzed from the value of a received framethat the frame is an error frame, the frame analyzing unit 402 discardsthat frame thereafter, i.e., stops analyzing the frame.

The reception ID judging unit 403 receives the value of the ID fieldnotified from the frame analyzing unit 402 and determines whether or notto receive the fields in the frame after that ID field, in accordancewith a CAN-ID list that the reception ID list storing unit 404 stores.The reception ID judging unit 403 notifies the determination resultsthereof to the frame analyzing unit 402.

The reception ID list storing unit 404 stores the reception ID list,that is a list of CAN-IDs that the master ECU 400 receives. FIG. 4illustrates an example of a reception ID list.

The expiration data confirming unit 405 acquires a value indicating theexpiration date of the shared key, that is the value of the data field,for an expiration date notification frame identified by the CAN-IDreceived from the frame analyzing unit 402, and inspects the expirationdate by comparing with the current point-in-time. In a case where theexpiration date has already elapsed, the expiration data confirming unit405 records this in a log. Also, in a case where the expiration date hasalready elapsed, the expiration data confirming unit 405 notifies thedriver by displaying information on the display device to the effectthat the expiration date has elapsed. In a case where the expirationdate has elapsed, the master ECU 400 can keep session keys from beingtransmitted to the ECUs.

The MAC processing unit 406 calculates a MAC value using a session keycorresponding to the CAN-ID that is stored in the session key liststoring unit 408, with regard to a value obtained by linking the CAN-IDnotified from the frame analyzing unit 402, a portion of the data fieldexcluding the MAC value, and a reception counter value corresponding tothe CAN-ID stored in the counter storing unit 407. The MAC processingunit 406 then performs comparison and verification against the MAC valueincluded in the data field, and notifies the verification results to theframe analyzing unit 402. The result of having obtained a MAC value bycalculation, with regard to the value (linked value) obtained by linkingthe CAN-ID notified from the frame generating unit 412, a value of datafor the data field to be transmitted, and a transmission counter valuecorresponding to the CAN-ID stored in the counter storing unit 407, isnotified to the frame generating unit 412. Advanced EncryptionStandard-Cipher-based Message Authentication Code (AES-CMAC, seeRFC4493: “The AES-CMAC Algorithm”) is used here as the MAC calculationmethod, with calculation being performed on the above-described linkedvalue using a MAC key (session key) of a value padded to a predeterminedblock worth, and the four leading bytes of the obtained calculationresults are taken as the MAC value. Note that the size of the MAC value,and the calculation method, are only an example, and these are notrestrictive. A MAC is generated reflecting a transmission counter valueincremented each time a frame is transmitted, so even if data framesincluding the same data are transmitted multiple times, for example, theMAC value given (i.e., added) to the data frame changes with eachtransmission.

The counter storing unit 407 stores counter values necessary forcalculating MAC values, one each for transmission and for receipt, foreach CAN-ID. In a case where a frame has been successfully transmitted,the transmission counter value is incremented, and in a case where aframe has been successfully received, the reception counter value isincremented.

The session key list storing unit 408 stores a list where session keysused for encryption processing relating to frames, i.e., session keysused by the MAC processing unit 406 to calculate MAC values, arecorrelated with CAN-IDs (session key list). The session key list storingunit 408 saves session keys notified from the encryption processing unit409 along with CAN-IDs as a session key list.

The encryption processing unit 409 receives a session key generatingrequest from the frame generating unit 412 along with a CAN-ID, notifiesthe session key generating unit 411 of the session key generatingrequest, and receives a session key generated and issued (transmitted)by the session key generating unit 411. The encryption processing unit409 encrypts the issued session key using a shared key (shared keycorresponding to the CAN-ID) stored in the shared key list storing unit410, and notifies the frame generating unit 412. The encryptionprocessing unit 409 also notifies the session key list storing unit 408of the session key issued by the session key generating unit 411 alongwith the CAN-ID, so as to be saved in the session key list storing unit408.

The shared key list storing unit 410 stores a shared key list that is alist correlating shared keys shared beforehand for use in transmissionof session keys among the ECUs, with the CAN-IDs. One shared key isdesignated for each CAN-ID. The correlation between a certain CAN-ID andshared key in the shared key list indicates the correlation between theECU transmitting the frame including that CAN-ID, and the shared key.Besides designating a shared key for each CAN-ID, one shared key may bedesignated for all ECUs. Alternatively, in a case where the bus 200 isof a configuration where multiple sub-nets are connected by a gateway,the bus 200 may designate one shared key for each sub-net (each set ofECUs connected to a sub-net). FIG. 5 illustrates an example of a sharedkey list that the shared key list storing unit 410 stores.

The session key generating unit 411 receives the session key generatingrequest, and generates and issues a session key. Examples of a sessionkey generating method include using a method of calculating a sessionkey using a hash function, which is a one-way function, from a serial IDunique to the master ECU 400. FIG. 6 illustrates an example of a sessionkey list, in which is described a session key that the session keygenerating unit 411 generates, and the session key list storing unit 408stores.

The frame generating unit 412 configures an error frame in accordancewith the error frame transmission request notified from the frameanalyzing unit 402, and notifies the frame transmission/reception unit401 to transmit the error frame. The frame generating unit 412 notifiesthe encryption processing unit 409 of the session key generatingrequest, and receives the encrypted session key. The frame generatingunit 412 notifies the MAC processing unit 406 of the CAN-ID decidedbeforehand, and the encrypted session key notified from the encryptionprocessing unit 409, and receives the MAC value calculation results. Theframe generating unit 412 configures a data frame to which is attachedthe encrypted session key received from the encryption processing unit409, the MAC value notified from the MAC processing unit 406, and thepredetermined CAN-ID, and notifies the frame transmission/reception unit401 to transmit the data frame.

The master ECU 400 has a function of, upon detecting that the vehicle inwhich the onboard network system 10 is installed is in an accessory-on(ACC-ON) state, causing the frame generating unit 412 to generate aninquiry frame for the expiration date of the shared key, andtransmitting to the frame transmission/reception unit 401. Vehiclestates such as starting the engine, ACC-ON, stopped, and so forth, maybe detected by detection mechanisms such as various types of sensors andso forth, and transmitted from the detection mechanisms directly to themaster ECU 400 or via other ECUs.

1.4 Reception ID List Example 1

FIG. 4 is a diagram illustrating an example of a reception ID list(CAN-ID list) that the master ECU 400 stores in the reception ID liststoring unit 404. The reception ID list illustrated in FIG. 4 is usedfor the master ECU 400 to selectively receive and process frames ofwhich the CAN-ID value is one of “1”, “2”, “3”, “4”, “101”, “102”,“103”, and “104”. In this example, the CAN-IDs “101”, “102”, “103”, and“104” of expiration date notification frames that the ECUs transmit arevalues obtained by adding a certain values to the CAN-IDs “1”, “2”, “3”,and “4” that these ECUs basically transmit.

1.5 Shared Key List Example

FIG. 5 is a diagram illustrating an example of a shared key list thatthe master ECU 400 stores in the shared key list storing unit 410. Theshared key list is a list where CAN-IDs and shared keys (Km) arecorrelated. The shared key list illustrated in FIG. 5 indicates thatshared key “0x1A4DE4FC02F66B77” has been assigned to CAN-ID “1”, sharedkey “0x27AB6EAC81773F65” has been assigned to CAN-ID “2”, shared key“0xCB939EA0CE378A7E” has been assigned to CAN-ID “3”, and shared key“0x03E46FF28CBC8D7A” has been assigned to CAN-ID

1.6 Session Key List Example

FIG. 6 is a diagram illustrating an example of a session key list thatthe master ECU 400 stores in the session key list storing unit 408. Thesession key list is a list where CAN-IDs and session keys (Ks) arecorrelated. The session key list illustrated in FIG. 6 indicates thatthe same session key “0x7678A87B” has been assigned to the CAN-IDs “1”,“2”, “3”, and “4”.

1.7 Configuration of ECU 100 a

FIG. 7 is a configuration diagram of the ECU 100 a. The ECU 100 a isconfigured including a frame transmission/reception unit 101, a frameanalyzing unit 102, a reception ID judging unit 103, a reception ID liststoring unit 104, a decryption processing unit 105, a shared key liststoring unit 106, a MAC processing unit 107, a session key storing unit108, a counter storing unit 109, a frame generating unit 110, and a dataacquisition unit 111. These components are functional components, andthe functions thereof are realized by a communication circuit in the ECU100 a, a processor or digital circuit of the like that executes thecontrol program stored in the memory, and so forth. The ECUs 100 bthrough 100 d also have basically the same configuration as the ECU 100a.

The frame transmission/reception unit 101 transmits and receives framesfollowing the CAN protocol to and from the bus 200. Frames are receivedfrom the bus 200 one bit at a time, and transferred to the frameanalyzing unit 102. The contents of frames received from the framegenerating unit 110 are transmitted to the bus 200.

The frame analyzing unit 102 receives the values of frames from theframe transmission/reception unit 101, and performs analysis so as tomap to the fields in the frame format stipulated in the CAN protocol.The frame analyzing unit 102 transfers a value determined to be an IDfield to the reception ID judging unit 103. The frame analyzing unit 102decides, in accordance with determination results notified from thereception ID judging unit 103, whether to transfer the value of an IDfield (CAN-ID) and a data field appearing after the ID field, to the MACprocessing unit 107, or to cancel reception of frames after havingreceived the determination results (i.e., to stop analyzing that frame).After transferring to the MAC processing unit 107, the processingresults at the MAC processing unit 107 (the MAC verification results)are received, and in a case of having been determined to be normal(i.e., in a case where MAC verification has been successful), the valueof the ID field and the data field appearing after the ID field arenotified to the decryption processing unit 105. In a case where theframe is judged not to be following the CAN protocol, the frameanalyzing unit 102 notifies the frame generating unit 110 to transmit anerror frame. In a case of having received an error frame, i.e., in acase of having analyzed from the value of a received frame that theframe is an error frame, the frame analyzing unit 102 discards thatframe thereafter, i.e., stops analyzing the frame.

The reception ID judging unit 103 receives the value of the ID fieldnotified from the frame analyzing unit 102 and determines whether or notto receive the fields in the frame after that ID field, in accordancewith a CAN-ID list that the reception ID list storing unit 104 stores.The reception ID judging unit 103 notifies the determination resultsthereof to the frame analyzing unit 102.

The reception ID list storing unit 104 stores the reception ID list,that is a list of CAN-IDs that the ECU 100 a receives. FIG. 8illustrates an example of a reception ID list that is a CAN-ID list.

The decryption processing unit 105 is notified of the encrypted sessionkey by the frame analyzing unit 102, along with a CAN-ID decidedbeforehand for transmission of the session key, and thereupon uses theshared key that the shared key list storing unit 106 stores to performdecryption processing, and acquires the session key. The acquiredsession key is notified to the session key storing unit 108 to be saved.In a case of having received notification from the frame analyzing unit102 of data along with a CAN-ID other than for session key transmission,the decryption processing unit 105 performs processing accordingfunctions that differ for each ECU, in accordance with the receiveddata. For example, the ECU 100 a connected to the engine 310 has afunction of sounding an alarm sound in a state where a door is open andthe speed is above 30 Km/hour. The ECU 100 a has a speaker or the likefor sounding the alarm sound, for example. the ECU 100 a manages data(e.g., information indicating the state of the door) received from otherECUs, and performs processing such as sounding an alarm sound underpredetermined conductions based on the speed acquired from the sharedengine 310, for example.

The shared key list storing unit 106 stores a shared key correspondingto the CAN-ID that the ECU 100 a uses for transmitting (i.e., the sharedkey corresponding to the ECU 100 a), and information indicating theexpiration date of that shared key. An example of a shared key stored bythe shared key list storing unit 106 will be described later withreference to FIG. 14.

The MAC processing unit 107 calculates a MAC value using a session keycorresponding to the CAN-ID that is stored in the session key storingunit 108, with regard to a value obtained by linking the CAN-ID notifiedfrom the frame analyzing unit 102, a portion of the data field excludingthe MAC value, and a reception counter value corresponding to the CAN-IDthat is stored in the counter storing unit 109. The MAC processing unit107 then performs comparison and verification against the MAC valueincluded in the data field, and notifies the verification results to theframe analyzing unit 102. The result of having obtained a MAC value bycalculation, with regard to the value (linked value) obtained by linkingthe CAN-ID notified from the frame generating unit 110, a value of datafor the data field to be transmitted, and a transmission counter valuecorresponding to the CAN-ID stored in the counter storing unit 109, isnotified to the frame generating unit 110. AES-CMAC (RFC4493: “TheAES-CMAC Algorithm”) is used here as the MAC calculation method, withcalculation being performed on the above-described linked value using aMAC key (session key) of a value padded to a predetermined block worth,and the four leading bytes of the obtained calculation results are takenas the MAC value. Note that the size of the MAC value, and thecalculation method, are only an example, and these are not restrictive.

The session key storing unit 108 stores the session key for encryptionprocessing relating to frames, i.e., the session key that the MACprocessing unit 107 uses for calculating MAC values, in a correlatedmanner with the CAN-ID that the ECU 100 a uses for transmission. Thesession key storing unit 108 saves the session key notified from thedecryption processing unit 105.

The counter storing unit 109 stores counter values necessary forcalculating MAC values, one each for transmission and for reception, foreach CAN-ID. In a case where a frame has been successfully transmitted,the transmission counter value is incremented, and in a case where aframe has been successfully received, the reception counter value isincremented.

The frame generating unit 110 configures an error frame in accordancewith the error frame transmission request notified from the frameanalyzing unit 102, and notifies the frame transmission/reception unit101 to transmit the error frame.

The frame generating unit 110 notifies the MAC processing unit 107 ofthe data field value decided based on the data notified from the dataacquisition unit 111, and receives the MAC value calculation results.The frame generating unit 110 configures a data frame from the datafield value decided based on the data notified from the data acquisitionunit 111, the MAC value notified from the MAC processing unit 107, andthe CAN-ID decided beforehand, and notifies the frametransmission/reception unit 101 to transmit the data frame.

The data acquisition unit 111 acquires data indicating the states ofdevices, sensors and the like, connected to the ECUs, and notifies theframe generating unit 110.

The ECU 100 a has a function of, upon receiving frame inquiring theexpiration date of a shared key, causing the frame generating unit 110to generate an expiration date notification frame in which theexpiration date is data and a MAC has been attached, and transmittingthe frame. The ECU 100 a and the other ECUs may have functions otherthan those exemplarily illustrated here. The contents of framestransmitted by each of the ECUs 100 a through 100 d will be describedlater with reference to FIGS. 10 through 13.

1.8 Reception ID List Example 2

FIG. 8 is a diagram illustrating an example of a reception ID list thatthe ECU 100 a and ECU 100 c each stores. The reception ID listillustrated in FIG. 8 is used to selectively receive and process framesof which the CAN-ID value is one of “1”, “3”, and so forth. Althoughomitted from illustration in FIG. 8, the reception ID list stored ineach of the ECU 100 a and ECU 100 c further includes a CAN-ID decidedbeforehand for transmitting a session key for each ECU, and a CAN-IDdecided beforehand for a shared key expiration date inquiry from themaster ECU 400.

1.9 Reception ID List Example 3

FIG. 9 is a diagram illustrating an example of a reception ID list thatthe ECU 100 b and ECU 100 d each stores. The reception ID listillustrated in FIG. 9 is used to selectively receive and process framesof which the CAN-ID value is one of “2”, “4”, and so forth. Althoughomitted from illustration in FIG. 9, the reception ID list stored ineach of the ECU 100 b and ECU 100 d further includes a CAN-ID decidedbeforehand for transmitting a session key for each ECU, and a CAN-IDdecided beforehand for a shared key expiration date inquiry from themaster ECU 400.

1.10 Example of Transmission Frame of ECU 100 a Relating to Engine

FIG. 10 is a diagram illustrating an example of a CAN-ID and data field(data) in frames transmitted from the ECU 100 a connected to the engine310. The CAN-ID of the frames that the ECU 100 a transmits relating tospeed is “1”. In the value in the data field, the first one byterepresents speed, the next one byte represents the counter (transmissioncounter value), and the next four bytes represent the MAC value. Thespeed (km/hour) assumes a range from a minimum of 0 (km/hour) to amaximum of 180 (km/hour). In order from the top row to lower rows inFIG. 10 is illustrated the CAN-IDs and data corresponding to the framessequentially transmitted from the ECU 100 a, representing the way inwhich acceleration is performed from 0 km/hour in 1 km/hour increments.

1.11 Example of Transmission Frame of ECU 100 b Relating to Brakes

FIG. 11 is a diagram illustrating an example of a CAN-ID and data field(data) in frames transmitted from the ECU 100 b connected to the brakes320. The CAN-ID of the frames that the ECU 100 b transmits relating tothe degree of braking is “2”. In the value in the data field, the firstone byte represents the degree of braking, the next one byte representsthe counter (transmission counter value), and the next four bytesrepresent the MAC value. The degree of braking is represented bypercentage (%), with a state where no braking is being performed at allbeing 0(%), and a state of full-braking is 100(%). In order from the toprow to lower rows in FIG. 11 is illustrated the CAN-IDs and datacorresponding to the frames sequentially transmitted from the ECU 100 b,representing the way in which braking is gradually being reduced from100%.

1.12 Example of Transmission Frame of ECU 100 c Relating to DoorOpened/Closed Sensor

FIG. 12 is a diagram illustrating an example of a CAN-ID and data field(data) in frames transmitted from the ECU 100 c connected to the dooropen/closed sensor 330. The CAN-ID of the frames that the ECU 100 ctransmits relating to the open/closed state of the door is “3”. In thevalue in the data field, the first one byte represents the open/closedstate of the door, the next one byte represents the counter(transmission counter value), and the next four bytes represent the MACvalue. The open/closed state of the door is represented by “1” for astate where the door is opened, and “0” for a state where the door isclosed. In order from the top row to lower rows in FIG. 12 isillustrated the CAN-IDs and data corresponding to the framessequentially transmitted from the ECU 100 c, representing the way inwhich the door transitions from an open state to a closed state.

1.13 Example of Transmission Frame of ECU 100 d Relating to WindowOpened/Closed Sensor

FIG. 13 is a diagram illustrating an example of a CAN-ID and data field(data) in frames transmitted from the ECU 100 d connected to the windowopen/closed sensor 340. The CAN-ID of the frames that the ECU 100 dtransmits relating to the open/closed state of the window is “4”. In thevalue in the data field, the first one byte represents the open/closedstate of the window, the next one byte represents the counter(transmission counter value), and the next four bytes represent the MACvalue. The open/closed state of the window is represented by percentage(%), with a state where the window is completely closed being 0(%), anda state where the window is completely open being 100(%). In order fromthe top row to lower rows in FIG. 13 is illustrated the CAN-IDs and datacorresponding to the frames sequentially transmitted from the ECU 100 d,representing the way in which the window is gradually transitioning froma closed state to an open state.

1.14 Shared Key that ECU 100 a Stores

FIG. 14 is a diagram illustrating the shared key that the ECU 100 astores, and information indicating the expiration date thereof. FIG. 14indicates that a shared key “0x1A4DE4FC02F66B77” having the expirationdate of “2034 Dec. 31” has been assigned to the CAN-ID “1” that the ECU100 a transmits. This shared key is used for decoding the session keytransmitted from the master ECU 400. Note that the shared key may be setto the ECU at the stage of manufacturing or shipping or the like of theECU, and updated by connecting a dedicated tool to the onboard networksystem 10.

1.15 Session Key Distribution Sequence

The following is a description of operations of the master ECU 400transmitting a session key to the ECU 100 a, with reference to FIG. 15.FIG. 15 is a diagram illustrating an example of a session keydistribution sequence performed between the master ECU 400 and the ECU100 a. Although the master ECU 400 distributes session keys to the ECUs100 b through 100 d in the same way, description will be made herefocusing on the ECU 100 a that is the ECU that transmits frames with theCAN-ID “1”.

First, the master ECU 400 generates a certain session key Ks1 at thesession key generating unit 411 (step S1001).

Next, the master ECU 400 uses the shared key Km (see FIG. 5)corresponding to the CAN-ID “1” to encrypt the session key Ks1 andgenerate an encrypted session key Ks1′ at the encryption processing unit409 (step S1002).

The master ECU 400 generates a MAC using the generated encrypted sessionkey Ks1′ and a counter (transmission counter value) at the MACprocessing unit 406 (step S1003).

The master ECU 400 transmits a data frame including in the data fieldthe encrypted session key Ks1′ and the MAC value, to which has beenattached the CAN-ID decided beforehand for transmission of the sessionkey to the ECU 100 a corresponding to the CAN-ID “1” (step S1004).Accordingly, the data frame appears on the bus 200.

The master ECU 400 starts receiving the data frame flowing on the bus toconfirm the transmitted frame (step S1005), confirms that the dataflowing on the bus matches the data frame which it is transmittingitself (step S1006), and if not matching, transmits an error frame (stepS1007).

When a data frame appears on the bus 200, the ECU 100 a starts receivingthe data frame flowing on the bus (step S1008).

The ECU 100 a receives the CAN-ID included in the data frame flowing onthe bus at the reception ID judging unit 103, and checks whether or notit is an ID listed in the reception ID list that the reception ID liststoring unit 104 stores (step S1009). In a case where the CAN-ID is aCAN-ID that is not listed in the reception ID list, the data frame beingreceived is discarded, and the frame reception ends. Note that theCAN-ID decided beforehand for session key transmission is listed in thereception ID list.

The ECU 100 a extracts the MAC value from the data field of the receiveddata frame and performs verification at the MAC processing unit 107(step S1010). In a case where verification fails, the data frame beingreceived is discarded, and the frame reception ends.

The ECU 100 a acquires the encrypted session key Ks1 from the receiveddata field, and extracts the session key Ks1 by performing decryptionprocessing at the decryption processing unit 105 using the shared keythat the shared key list storing unit 106 stores (step S1011). In a casewhere decryption fails, processing regarding the received frame ends.

The ECU 100 a saves the extracted session key Ks1 in the session keystoring unit 108 (step S1012). The ECU 100 a uses this session key Ks1to generate or verify MAC values at the time of transmission orreception of the next and subsequent data frames.

The ECUs 100 b through 100 d can each use a shared key shared with themaster ECU 400 so as to acquire the session key Ks1 from the master ECU400 in the same way as the ECU 100 a.

1.16 Message Authentication Sequence

The following is a description of operations of message authenticationrelating to transmission of a data frame between the ECU 100 a and theECU 100 c, with reference to FIG. 16.

FIG. 16 is a diagram illustrating an example of a message authenticationsequence performed between the ECU 100 a and ECU 100 c. Although messageauthentication between the ECU 100 a and the ECU 100 c is illustratedhere, the same operations are performed between other ECUs, between theECU 100 b and ECU 100 d for example, between the ECU 100 a and themaster ECU 400, and so forth. The ECU 100 c has basically the sameconfiguration as the ECU 100 a, so components of the ECU 100 c will bereference using the same reference numerals as for the components of theECU 100 a (See FIG. 7).

First, the ECU 100 a generates data to be transmitted at the framegenerating unit 110 (step S1101).

The ECU 100 a then generates a MAC corresponding to the value of thedata generated in step S1101 and the counter (transmission countervalue) at the MAC processing unit 107 (step S1102). The ECU 100 a usesthe session key Ks1 stored in the session key storing unit 108 togenerate this MAC.

Next, the ECU 100 a increments the transmission counter valuecorresponding top the CAN-ID “1” by 1 (step S1103).

The ECU 100 a transmits the data frame including the value of the dataand the counter in the data field, with the CAN-ID “1” attached, by theframe transmission/reception unit 101 (step S1104). Accordingly, thedata frame appears on the bus 200.

The ECU 100 a starts receiving the data frame flowing on the bus toconfirm the transmitted frame (step S1105), confirms that the dataflowing on the bus matches the data frame which it is transmittingitself (step S1106), and if not matching, transmits an error frame (stepS1107).

When a data frame appears on the bus 200, the ECU 100 c starts receivingthe data frame flowing on the bus (step S1108).

The ECU 100 c receives the CAN-ID included in the data frame flowing onthe bus at the reception ID judging unit 103, and checks whether or notit is an ID listed in the reception ID list (see FIG. 8) that thereception ID list storing unit 104 stores (step S1109). In a case wherethe CAN-ID is a CAN-ID that is not listed in the reception ID list, thedata frame being received is discarded, and the frame reception ends.

The ECU 100 c extracts the MAC value from the data field of the receiveddata frame and performs verification at the MAC processing unit 107(step S1110). In a case where verification fails, the data frame beingreceived is discarded, and the frame reception ends. The ECU 100 c usesthe session key Ks1 stored at the session key storing unit 108 in theverification of the MAC in step S1110. In a case where verification hasbeen successful, the ECU 100 c increments the reception counter valuecorresponding to the CAN-ID “1” by 1 (step S1111).

Following step S1111, the ECU 100 c performs processing in accordancewith the received data frame (step S1112).

1.17 Shared Key Verification Sequence

The following is a description of operations of the master ECU 400inspecting (verifying) the security state relating to shared keys, byconfirmation of the expiration date, with reference to FIG. 17.

FIG. 17 illustrates an example of a shared key verification sequence bythe master ECU 400, the ECU 100 a, the ECU 100 b, the ECU 100 c, and theECU 100 d. Note that this shared key verification sequence is executedwhen the vehicle in which is installed the onboard network system 10 isin a particular state (e.g., a stopped state before driving), forexample. As for a specific example, this is executed immediately afterentering the accessory-on (ACC-ON) state.

The master ECU 400 transmits an expiration date inquiry frame regardingthe shared keys that the ECUs store shared with the master ECU 400 (stepS1201). Accordingly, an expiration date inquiry frame appears on the bus200.

The ECUs 100 a through 100 d each receive the expiration date inquiryframe from the bus 200, and transmit an expiration date notificationframe including data, where the MAC has been attached to the expirationdate of the shared key that each store, in the data field (step S1202).That is to say, the ECU 100 a, the ECU 100 b, the ECU 100 c, and the ECU100 d transmit expiration date notification frames to which therespective CAN-IDs “101”, “102”, “103”, and “104”, have been attached.Accordingly, the expiration date notification frames sequentially appearon the bus 200.

The master ECU 400 verifies the MAC values included in the expirationdate notification frames sequentially appearing on the bus 200, andcompares the expiration date included in the expiration datenotification frames with the current point-in-time, thereby confirmingthat the expiration date of the shared keys obtained from all ECUs islater than the current point-in-time (i.e., that all of the shared keysare within the expiration date) (step S1203). If there is a shared keythat is not within the expiration date, the master ECU 400 records andsaves information indicating that the expiration date has elapsed in alog (step S1204), and displays information on the display devicerelating to the fact that the expiration date has elapsed (informationindicating that updating of the shared key is necessary and so forth),thus making notification to the driver (step S1205). Note that in a casewhere the expiration date of any one of the shared keys has elapsed, forexample, the master ECU 400 can keep session keys from beingtransmitted.

1.18 Advantages of First Embodiment

In the onboard network system 10 according to the first embodiment, themaster ECU 400 (a first-type ECU serving as a key managing device so asto speak) confirms (inspects) the expiration date of the shared keysthat the ECUs (second-type ECU) store, in a case where the vehicle is ina particular state, such as a stopped state, thereby inspecting whetheror not the risk of leakage of the shared keys that the ECUs store hasincreased (whether or not a state where updating of the shared key isnecessary) with regard to security. That is to say, a first-type ECUreceives a frame including information indicating the expiration date ofa shared key that a second-type ECU stores and distinguishes whether ornot the expiration date has already elapsed, thereby inspecting thesecurity state of the shared key, and performs communication to give thesecond-type ECU a session key in a case where the expiration date hasnot expired, while performing control such as notification or the like(display on the display device or the like) in a case where theexpiration date has elapsed. The shared keys that the ECUs (second-typeECU) store are shared between the ECUs and the master ECU (first-typeECU), and are used for transmission of session keys. The session keysare used as keys in encryption processing (processing includinggenerating and verifying MACs, etc.) when transmitting and receivingframes among the ECUs. This encryption processing may include varioustypes of conversion processing, such as encryption, decryption, signing,verification, and so forth. Accordingly, in a case where the securitystate is unsuitable (in a case where the risk of leakage of a shared keyis higher) in the onboard network system 10 where the security state ofshared keys is configured using the expiration date, safety can besecured by notification, recording in a log, and so forth, and therebycan prevent distribution of invalid session keys. Performing the sharedkey security state inspection in a stopped state before the vehicledrives, such as at the time of ACC-ON, and avoiding increased processingload on the ECUs and increased traffic on the bus 200 while the vehicleis driving, is useful.

1.19 Modification of First Embodiment

The onboard network system 10 including a master ECU 1400 (key managingdevice) which is a partial modification of the above-described masterECU 400 will be described below.

The master ECU 1400 is basically the same as the master ECU 400, but themethod of verifying the expiration date of the shared keys that the ECUsstore differs. That is to say, the master ECU 1400 has a function ofverifying the expiration date of the shared keys that the ECUs store bycommunication with a server that is external from the onboard networksystem 10 (outside of the vehicle).

1.20 Configuration of Master ECU 1400

FIG. 18 is a configuration diagram of the master ECU 1400. The masterECU 1400 includes the frame transmission/reception unit 401, the frameanalyzing unit 402, the reception ID judging unit 403, the reception IDlist storing unit 404, the MAC processing unit 406, the counter storingunit 407, the session key list storing unit 408, the encryptionprocessing unit 409, the shared key list storing unit 410, the sessionkey generating unit 411, the frame generating unit 412, and a servercommunication unit 1412. These components are functional components, andthe functions thereof are realized by a communication circuit in themaster ECU 1400, a processor or digital circuit of the like thatexecutes the control program stored in the memory, and so forth. Notethat the components of the master ECU 1400 that are the same as thecomponents of the master ECU 400 (see FIG. 3) are denoted by the samereference numerals, and description will be omitted as appropriate.

In a case of having succeeded in verification, as the result ofverifying a MAC of a data frame at the MAC processing unit 406, theframe analyzing unit 402 notifies the server communication unit 1412 ofthe CAN-ID of the frame and the value of the data field.

The server communication unit 1412 has a function of communicating withan external server wirelessly. The server communication unit 1412correlates the CAN-IDs of all data frames received from the frameanalyzing unit 402 and the values of the data fields, notifies theserver, and receives determination results from the server. In a casewhere an error occurs as a result of determination, the driver isnotified by displaying the content of the error on the display device,for example. In a case where the determination results at the serverregarding an expiration date notification frame are an error, the masterECU 1400 can keep transmission of session keys to the ECUs from beingperformed.

Note that the external server is a computer communicable with the masterECU 1400, and has a function of, in a case of having received from themaster ECU 1400 a CAN-ID regarding an expiration date notification frameand a value indicating the expiration date that is the value of the datafield, making judgment regarding whether or not the expiration date haselapsed, based on the current point-in-time or other information. In acase where this has not elapsed, a determination result of normal istransmitted to the master ECU 1400, and if this has elapsed, an error istransmitted.

1.21 Shared Key Verification Sequence

The following is a description of operations of the master ECU 1400inspecting the security state relating to shared keys, by communicationwith the server, with reference to FIG. 19.

FIG. 19 illustrates an example of a shared key verification sequence bythe master ECU 1400, the ECU 100 a, the ECU 100 b, the ECU 100 c, andthe ECU 100 d. Note that this shared key verification sequence isexecuted when the vehicle in which is installed the onboard networksystem 10 is in a particular state (e.g., a stopped state beforedriving), for example. As for a specific example, this is executedimmediately after entering the accessory-on (ACC-ON) state. Note thatprocessing (steps) in FIG. 19 that are the same as those shown in FIG.17 are denoted by the same reference numerals, and description will beomitted here.

In step S1202, expiration date notification frames transmitted by theECU 100 a, ECU 100 b, ECU 100 c, and ECU 100 d sequentially appear onthe bus 200.

The master ECU 1400 transmits to the server the CAN-IDs of theexpiration date notification frames sequentially appearing on the bus200 and the values included in the expiration date notification frames.Confirmation is made regarding whether or not the expiration date of theshared keys has not elapsed, by whether or not the determination resultsreturned from the server are normal (step S1303). In a case where thedetermination results form the server are an error, i.e., the expirationdate of the shared key has expired, the master ECU 1400 notifies thedrive by display information relating to the fact that the expirationdate has expired (information indicating that the updating of the sharedkey is necessary, etc.) on the display device (step S1304). Note that ina case where the expiration date of any one of the shared keys haselapsed, for example, the master ECU 1400 can keep session keys frombeing transmitted.

1.22 Advantages of Modification of First Embodiment

In the onboard network system 10 according to the modification of thefirst embodiment, the master ECU 1400 communicates with an externalserver in a case where the vehicle is in a particular state such as astopped state or the like, and causes the server to determine theexpiration date of shared keys that the ECUs store, thereby verifyingwhether or not the security state of the shared keys is appropriate,i.e., whether or not the state is that where the risk of leakage ofshared keys stored by the ECUs is higher (whether or not a state wherethe shared keys need to be updated). In a case where the security stateis inappropriate, safety can be secured by notification and the like,and distribution of unauthorized session keys can be prevented. Theexternal server can collect information of the expiration date of theshared keys of the ECUs from the master ECU 400 in the onboard networksystem 10 installed in each of multiple vehicles and confirm theintegrity, so the security state of the shared keys can be determinedmore appropriately.

Second Embodiment

As an embodiment of the present disclosure, an onboard network systemwill be described including a master ECU (key managing device) 20400that saves a shared key list, which is information correlating CAN-IDsand serial IDs for each ECU, and verifies the security state of theshared keys based on the shared key list. The onboard network systemaccording to the present embodiment has the master ECU 400 in theonboard network system 10 according to the first embodiment (see FIG. 1)replaced with the master ECU 20400 (described later). The onboardnetwork system according to the present embodiment has the ECU 100 a inthe onboard network system 10 according to the first embodiment replacedwith a ECU 20100 a (described later) having a function of storing aserial ID unique to the ECU and transmitting a serial ID notificationframe to make notification of this serial ID. The onboard network systemaccording to the present embodiment also has ECUs 20100 b through 20100d having the same function as the ECU 20100 a, instead of the ECUs 100 bthrough 100 d.

2.1 Configuration of Master ECU 20400

In the same way as the master ECU 400, the master ECU 20400 is connectedto the bus 200, as a type of ECU serving as a key managing device. Themaster ECU 20400 stores a shared key shared with one or more ECUs out ofthe multiple ECUs connected to the bus 200 besides itself, to use fortransmitting session keys mutually between the one or more ECUs forencryption processing relating to frames (including MAC processing), andfunctions to manage the security state of the shared key.

FIG. 20 is a configuration diagram of the master ECU 20400. The masterECU 20400 includes the frame transmission/reception unit 401, the frameanalyzing unit 402, the reception ID judging unit 403, the reception IDlist storing unit 404, the MAC processing unit 406, the counter storingunit 407, the session key list storing unit 408, the encryptionprocessing unit 409, a shared key list storing unit 20410, the sessionkey generating unit 411, the frame generating unit 412, and a listconfirmation unit 20421. Note that the components that are the same asthose shown in the first embodiment are denoted by the same referencenumerals, and description will be omitted as appropriate.

The shared key list storing unit 20410 stores a shared key list that isa list correlating shared keys shared beforehand for use in transmissionof session keys among the ECUs, with the CAN-IDs, and furthercorrelating serial IDs for each ECU. For each CAN-ID, there aredesignated the serial ID of one ECU that transmits a frame with thatCAN-ID, and one corresponding shared key. Besides designating a sharedkey for each CAN-ID, one shared key may be designated for all ECUs ormultiple ECUs. In this case, multiple serial IDs correspond to a singleshared key. Alternatively, in a case where the bus 200 is of aconfiguration where multiple sub-nets are connected by a gateway, thebus 200 may designate one shared key for each sub-net (each set of ECUsconnected to a sub-net). FIG. 21 illustrates an example of a shared keylist that the shared key list storing unit 20410 stores.

In a case of having succeeded in verification as a result of theverification of the MAC of the data frame in the MAC processing unit406, the frame analyzing unit 402 notifies the list confirmation unit20421 of the CAN-ID of that data frame and the value of the data field.

The list confirmation unit 20421 acquires a value indicating a serial IDunique to the ECU that is the transmission source of the frame at theframe analyzing unit 402, the value being a value of the data field of aserial ID notification frame identified by the CAN-ID, and compares withthe serial ID in the shared key list that the shared key list storingunit 410 stores, to determine whether matching or not. In a case wherethe serial IDs do not match, the list confirmation unit 20421 performserror processing, of recording in a log or the like. Another example oferror processing besides recording in a log include displayinginformation relating to the error on the display device, therebynotifying the driver, not performing transmission of session keys to theECUs, and so forth.

Note that the reception ID list that the reception ID list storing unit404 stores has listed the CAN-IDs “201”, “202”, “203”, and “204”, of theserial ID notification frames that the ECUs 20100 a through 20100 dtransmit, instead of the CAN-IDs “101”, “102”, “103”, and “104”. Of theexpiration date notification frames illustrated in the first embodiment.In the example of the CAN-IDs used here, the CAN-IDs “201”, “202”,“203”, and “204” of serial ID notification frames that the ECUs transmitare values obtained by adding a certain values to the CAN-IDs “1”, “2”,“3”, and “4” that these ECUs basically transmit.

2.2 Shared Key List Example

FIG. 21 is a diagram illustrating an example of a shared key list thatthe master ECU 20400 stores in the shared key list storing unit 20410.The shared key list is a list where CAN-IDs and shared keys (Km) andserial IDs are correlated. The serial ID is an ID unique to each ECU.The manufacture or the like of the ECUs, for example, gives the ECUsindividual serial IDs. The shared key list illustrated in FIG. 21indicates that shared key “0x1A4DE4FC02F66B77” and serial ID“0x10000001” have been assigned to CAN-ID “1”, shared key“0x27AB6EAC81773F65” and serial ID “0x10000002” have been assigned toCAN-ID “2”, shared key “0xCB939EA0CE378A7E” and serial ID “0x10000003”have been assigned to CAN-ID “3”, and shared key “0x03E46FF28CBC8D7A”and serial ID “0x10000004” have been assigned to CAN-ID “4”.

2.3 Configuration of ECU 20100 a

FIG. 22 is a configuration diagram of the ECU 20100 a. The ECU 20100 ais configured including the frame transmission/reception unit 101, theframe analyzing unit 102, the reception ID judging unit 103, thereception ID list storing unit 104, the decryption processing unit 105,the shared key list storing unit 106, the MAC processing unit 107, thesession key storing unit 108, the counter storing unit 109, the framegenerating unit 110, the data acquisition unit 111, and a serial IDstoring unit 20121. These components are functional components, and thefunctions thereof are realized by a communication circuit in the ECU20100 a, a processor or digital circuit of the like that executes thecontrol program stored in the memory, and so forth. The ECUs 20100 bthrough 20100 d also have basically the same configuration as the ECU20100 a. Components of the ECU 20100 a that are the same as thecomponents of the ECU 100 a (see FIG. 7) will be denoted with the samereference numerals, and description will be omitted here.

The serial ID storing unit 20121 stores a serial ID that is an ID uniqueto the ECU 20100 a.

The frame generating unit 110 acquires a serial ID that the serial IDstoring unit 20121 stores when generating a serial ID notificationframe. The frame generating unit 110 generates a serial ID notificationframe including the acquired serial ID and a MAC value generated by theMAC processing unit 107 corresponding to that serial ID, in the datafield.

The ECU 20100 a has a function of causing the frame generating unit 110to generate a serial ID notification frame, and of transmitting theserial ID notification frame, in a case where a serial ID inquiry framehas been received from the master ECU 20400.

2.4 Shared Key Verification Sequence

The following is a description of operations of the master ECU 20400inspecting the security state relating to shared keys, by confirmationof the serial ID, with reference to FIG. 23.

FIG. 23 illustrates an example of a shared key verification sequence bythe master ECU 20400, the ECU 20100 a, the ECU 20100 b, the ECU 20100 c,and the ECU 20100 d. Note that this shared key verification sequence isexecuted when the vehicle in which is installed the onboard networksystem 10 is in a particular state (e.g., a stopped state beforedriving), for example. As for a specific example, this is executedimmediately after entering the accessory-on (ACC-ON) state.

The master ECU 20400 transmits a frame for inquiry of serial IDs thatthe ECUs have (step S2101). Thus, the serial ID inquiry frame appears onthe bus 200.

The ECUs 20100 a through 20100 d each receive the serial ID inquiryframe from the bus 200, and transmit a serial ID notification frameincluding data in the data field where a MAC has been attached to theserial ID that each stores (step S2102). That is to say, the ECU 20100a, ECU 20100 b, ECU 20100 c, and ECU 20100 d respectively transmitserial ID notification frames to which are attached CAN-IDs “201”,“202”, “203”, “204”. Thus, the serial ID notification framessequentially appear on the bus 200.

With regard to the serial ID notification frames sequentially appearingon the bus 200, the master ECU 20400 verifies the MAC value included ineach serial ID notification frame, and matches the serial ID included inthe serial ID notification frame with the serial ID in the shared keylist stored in the shared key list storing unit 20410, therebydetermining whether or not the correlation between the shared key andserial ID has been changed (step S2103). Specifically, in a case wherethe CAN-ID of the serial ID notification frame is “201” for example, theCAN-ID “1” identified by subtracting or the like a particular valuecorresponding to the “201”, and the corresponding serial ID in theshared key list, are identified, the serial ID and the serial IDincluded in the serial ID notification frame are compared, and if theserial IDs match (the correlation between the shared key and serial IDhas not been changed), determination is made that the state is normal.If these do not match, determination is made that this is an error.

In a case where the results of the determination in step S2103 are notnormal, the master ECU 20400 transmits a message (frame) notifying anerror (step S2104). When a message notifying an error is flowing on thebus 200, a particular ECU receives this, and the particular ECU performserror notification (generating a sound indicating an error, an errordisplay, lighting an error lamp, etc.). Note that the master ECU 20400may transmit a message and relegate error processing to another ECU, ormay display the error on the display device, may save informationrelating to the error in a log, and may notify an external server of theerror. In a case where determination is made of an error, the master ECU20400 may keep session keys from being transmitted.

2.5 Advantages of Second Embodiment

In the onboard network system according to the second embodiment, themaster ECU 20400 (a first-type ECU serving as a key managing device soas to speak) confirms (inspects) the serial ID of the shared keys thatthe ECUs (second-type ECU) store, in a case where the vehicle is in aparticular state, such as a stopped state, and confirm that an ECU withan unauthorizedly copied shared key or the like has not been added.Accordingly, confirming the serial ID enables verification of thesecurity state of the shared keys, i.e., enables confirmation of whetheror not the risk of leakage of the shared keys that the ECUs store hasincreased. That is to say, a first-type ECU receives a frame includinginformation indicating the serial ID from a second-type ECU, anddistinguishes whether or not the security state of the shared key issuitable based on the serial ID and predetermined matching informationstored beforehand (e.g., a shared key list), and performs communicationto give the second-type ECU a session key in a case where the securitystate of the shared key is suitable, while performing control such asnotification or the like in a case where the security state of theshared key is not suitable. Performing the shared key security stateinspection in a stopped state before the vehicle drives, such as at thetime of ACC-ON, and avoiding increased processing load on the ECUs andincreased traffic on the bus 200 while the vehicle is driving, isuseful. As for a method of the first-type ECU distinguishing whether ornot the security state of the shared key is suitable based on the serialID received from the second-type ECU and the matching information(shared key list or the like), the serial ID may be directly comparedwith the matching information to distinguish whether matching or not, orthe result of having performed predetermined computation on the serialID may be compared with the matching information.

2.6 Modification of Second Embodiment

The onboard network system including a master ECU 21400 (key managingdevice) which is a partial modification of the above-described masterECU 20400 will be described below. The master ECU 21400 is basically thesame as the master ECU 20400, but the method of verifying the serial IDthat the ECUs store differs. That is to say, the master ECU 1400 has afunction of verifying the serial IDs of the ECUs by communication with aserver that is external from the onboard network system (outside of thevehicle). This server is a computer that manages information correlatingCAN-IDs and the serial IDs of each of the ECUs.

2.7 Configuration of Master ECU 21400

FIG. 24 is a configuration diagram of the master ECU 21400. The masterECU 21400 includes the frame transmission/reception unit 401, the frameanalyzing unit 402, the reception ID judging unit 403, the reception IDlist storing unit 404, the MAC processing unit 406, the counter storingunit 407, the session key list storing unit 408, the encryptionprocessing unit 409, the shared key list storing unit 20410, the sessionkey generating unit 411, the frame generating unit 412, and a servercommunication unit 21412. These components are functional components,and the functions thereof are realized by a communication circuit in themaster ECU 21400, a processor or digital circuit of the like thatexecutes the control program stored in the memory, and so forth. Notethat the components of the master ECU 21400 that are the same as thecomponents of the master ECU 400 or master ECU 20400 (see FIGS. 3 and20) are denoted by the same reference numerals, and description will beomitted as appropriate.

In a case of having succeeded in verification, as the result ofverifying a MAC of a data frame at the MAC processing unit 406, theframe analyzing unit 402 notifies the server communication unit 21412 ofthe CAN-ID of the data frame and the value of the data field.

The server communication unit 21412 has a function of communicating withan external server wirelessly. The server communication unit 21412correlates the CAN-IDs of all data frames received from the frameanalyzing unit 402 and the values of the data fields, notifies theserver, and receives determination results from the server. In a casewhere an error occurs as a result of determination, the driver isnotified by displaying the content of the error on the display device,for example. In a case where the determination results at the serverregarding a serial ID notification frame are an error, the master ECU21400 can keep transmission of session keys to the ECUs from beingperformed.

Note that the external server is a computer communicable with the masterECU 21400, and has a function of, in a case of having received from themaster ECU 21400 a CAN-ID regarding an serial ID notification frame anda value indicating the serial ID that is the value of the data field,identifying the transmission source ECU from the CAN-ID set to each ECUbeforehand, and making judgment regarding whether or not the serial IDmanaged correlated with that ECU and the received serial ID match. In acase where these match, a determination result of normal is transmittedto the master ECU 21400, and if not matching, an error is transmitted.

2.8 Shared Key Verification Sequence

The following is a description of operations of the master ECU 21400inspecting the security state relating to shared keys, with reference toFIG. 25. FIG. 25 illustrates an example of a shared key verificationsequence by the master ECU 21400, the ECU 20100 a, the ECU 20100 b, theECU 20100 c, and the ECU 20100 d. Note that this shared key verificationsequence is executed when the vehicle in which is installed the onboardnetwork system is in a particular state (e.g., a stopped state beforedriving), for example. As for a specific example, this is executedimmediately after entering the accessory-on (ACC-ON) state. Note thatprocessing (steps) in FIG. 25 that are the same as those shown in FIG.23 are denoted by the same reference numerals, and description will beomitted here.

In step S2102, serial ID notification frames transmitted by the ECU20100 a, ECU 20100 b, ECU 20100 c, and ECU 20100 d sequentially appearon the bus 200.

The master ECU 21400 transmits to the external server the CAN-IDs of theserial ID notification frames sequentially appearing on the bus 200 andthe serial ID included in the serial ID notification frames.Confirmation is made regarding whether or not the security state of theshared keys is suitable, by whether or not the determination resultsreturned from the server are normal (step S2203). In a case where thedetermination results from the server are an error, i.e., the serial IDdoes not match, the master ECU 21400 notifies the driver by display ofinformation indicating an error (information indicating that there is anunauthorized ECU, etc.) on the display device (step S2204).

2.9 Advantages of Modification of Second Embodiment

In the onboard network system according to the modification of thesecond embodiment, the master ECU 21400 communicates with an externalserver in a case where the vehicle is in a particular state such as astopped state or the like, and causes the server to determine whetherthe serial IDs that the ECUs store are suitable, thereby verifyingwhether or not the security state of the shared keys is appropriate. Ina case where the configuration of the onboard network system has beenchanged to where the correlation between the ECU and the serial IDmanaged by the server differs, such as in a case where an unauthorizedECU with an unauthorizedly copied shared key is connected to the onboardnetwork system, this is determined to be an error by the server. In acase where the security state is inappropriate, safety can be secured bynotification and the like. The external server can collect informationof the serial IDs of the ECUs from the master ECU 21400 in the onboardnetwork system and confirm the integrity, so the security state of theshared keys can be determined more appropriately.

Third Embodiment

As an embodiment of the present disclosure, an onboard network systemwill be described including a master ECU (key managing device) 30400that inspects the security state of the shared key by confirming theorder of responses from the ECUs as to a survival confirmation frame.The onboard network system according to the present embodiment has themaster ECU 400 in the onboard network system 10 according to the firstembodiment (see FIG. 1) replaced with the master ECU 30400 (describedlater), and the ECUs 100 a through 100 d replaced with the ECUs 20100 athrough 20100 d.

3.1 Configuration of Master ECU 30400

In the same way as the master ECU 400, the master ECU 30400 is connectedto the bus 200, as a type of ECU serving as a key managing device. Themaster ECU 30400 stores a shared key shared with one or more ECUs out ofthe multiple ECUs connected to the bus 200 besides itself, to use fortransmitting session keys mutually between the one or more ECUs forencryption processing relating to frames (including MAC processing), andfunctions to manage the security state of the shared key. The master ECU30400 transmits a survival confirmation frame requesting each ECU totransmit information (response), stores the order in which the responseof each ECU has been received, and compares the order of having receivedthe responses in accordance with the state of the vehicle, therebyinspecting the security state of the shared key. Description will bemade here where a serial ID notification frame including a serial ID istransmitted, as an example of transmission of information from each ECUas a response to the survival confirmation frame.

FIG. 26 is a configuration diagram of the master ECU 30400. Asillustrated in FIG. 26, the master ECU 30400 includes the frametransmission/reception unit 401, the frame analyzing unit 402, thereception ID judging unit 403, the reception ID list storing unit 404,the MAC processing unit 406, the counter storing unit 407, the sessionkey list storing unit 408, the encryption processing unit 409, theshared key list storing unit 20410, the session key generating unit 411,the frame generating unit 412, a sequence verifying unit 30431, and asequence recording unit 30432. Note that the components that are thesame as those shown in the first and second embodiments are denoted bythe same reference numerals, and description will be omitted asappropriate.

The reception ID list that the reception ID list storing unit 404 storesincludes CAN-IDs of serial ID notification frames of the ECUs, as shownin the second embodiment. In a case of having succeeded in verificationas a result of the verification of the MAC of the data frame in the MACprocessing unit 406, the frame analyzing unit 402 notifies the sequenceverifying unit 30431 of the CAN-ID of that data frame and the value ofthe data field.

The sequence verifying unit 30431 acquires from the frame analyzing unit402 a set of CAN-ID and data field value regarding a serial IDnotification frame identified by the CAN-ID, received as a response to afirst survival confirmation frame, and records this as a sequencerecording list by notifying the sets in the order of acquisition to thesequence recording unit 30432. The sequence verifying unit 30431 readsout from the sequence recording unit 30432 the sequence recording listwhere the sets of CAN-ID and data field value recorded the previous timehave been ordered, and confirms whether or not this matches the order ofthe sets acquired from the frame analyzing unit 402. In a case where theorder of receipt of serial ID notification frames form the ECUs asresponses to the survival confirmation frame differ between the previoustime and this time, the sequence verifying unit 30431 performs errorprocessing such as displaying an error on the display device. Besidesdisplaying an error, other examples or error processing may includerecording in a log, keeping session keys from being transmitted to theECUs, and so forth. The sequence verifying unit 30431 may furtherconfirm the serial IDs based on the shared key list stored in the sharedkey list storing unit 20410, as with the list confirmation unit 20421 inthe second embodiment, for example.

The sequence recording unit 30432 records the set of CAN-ID and datafield value as a sequence recording list, in the order of notification.Note that this may recorded with only the CAN-ID correlated with theorder (number). In this case, the sequence verifying unit 30431 notifiesthe received CAN-IDs n the order of reception to the sequence recordingunit 30432 so as to be recorded, and confirms whether or not the orderof the CAN-IDs received this time matches the order of CAN-IDs recordedthe previous time.

3.2 Example of Sequence Recording List

FIG. 27 illustrates an example of a sequence recording list. The examplein this drawing indicates that serial ID notification frames have beentransmitted in the order of CAN-IDs “201”, “202”, “203”, and “204”, asresponses to the previous survival confirmation frame.

3.3 Shared Key Verification Sequence

The following is a description of operations of the master ECU 30400inspecting the security state relating to shared keys, by confirmationof the order of responses from the ECUs to the survival confirmationframe, with reference to FIG. 28.

FIG. 28 illustrates an example of a shared key verification sequence bythe master ECU 30400, the ECU 20100 a, the ECU 20100 b, the ECU 20100 c,and the ECU 20100 d. Note that this shared key verification sequence isexecuted when the vehicle in which is installed the onboard networksystem is in a particular state (e.g., a stopped state before driving),for example. As for a specific example, this is executed immediatelyafter entering the accessory-on (ACC-ON) state and immediately afterentering the accessory-off (ACC-OFF) state.

The master ECU 30400 transmits a survival confirmation frame to each ofthe ECUs (step S3101). Thus, the survival confirmation frame appears onthe bus 200.

The ECUs 20100 a through 20100 d each receive the survival confirmationframe from the bus 200, and transmit a serial ID notification frameincluding data in the data field where a MAC has been attached to theserial ID that each stores (step S3102). After having received thesurvival confirmation frame, the ECUs each standby for a standby timeunique to each ECU, and then transmit the serial ID notification frameas a response to the survival confirmation frame. In the example in FIG.28, the ECU 20100 a, ECU 20100 b, ECU 20100 c, and ECU 20100 drespectively transmit serial ID notification frames to which areattached CAN-IDs “201”, “202”, “203”, “204”, in that order. Thus, theserial ID notification frames sequentially appear on the bus 200.

With regard to the serial ID notification frames sequentially appearingon the bus 200, the master ECU 30400 records the CAN-IDs of the serialID notification frames as a sequence recording list in the order ofreception (step S3103). The master ECU 30400 compares the order ofreception of CAN-IDs that are the responses this time with the order ofreception the previous time, based on the record of CAN-ID receptionorder relating to responses obtained at the time of having transmittedthe survival confirmation frame the previous time (the sequencerecording list recorded the previous time), and distinguishes whether ornot the order of reception is the same as the previous time (stepS3104). If not the same, an error is displayed on the display device(step S3105). Note that in step S3104 the master ECU 30400 may determinenot only the order of reception, but further whether or not the set ofserial IDs acquired from the received CAN-ID and data field are the sameas the previous time. Besides displaying an error on the display devicein step S3105, the error may be recorded in a log, notified to anexternal server, a message (frame) notifying the error may betransmitted, or the like. When a message notifying an error is flowingon the bus 200, a particular ECU may receive this, and the particularECU may perform error notification (generating a sound indicating anerror, an error display, lighting an error lamp, etc.).

3.4 Advantages of Third Embodiment

In the onboard network system according to the third embodiment, in astate where the vehicle is in a particular state, such as in a stoppedstate or the like, the master ECU 30400 (a first-type ECU serving as akey managing device so as to speak) transmits a survival confirmationframe as a request to the ECU 20100 a, ECU 20100 b, ECU 20100 c, and ECU20100 d, (second-type ECUs), and confirms the order in which responsesas responses to this request (serial ID notification frames) appear onthe bus 200, and thus can confirm whether the configuration of theonboard network system has been changed. That is to say, the first-typeECU confirms (inspects) the order of responses by distinguishing whetherthe CAN-IDs have been received in the order of a predetermined orderlist (e.g., the sequence recording list recorded the previous time),based on the CAN-IDs of the frames sequentially received from themultiple second-type ECUs after having transmitted the frame indicatinga predetermined request (e.g., survival confirmation frame).Accordingly, confirming the response order enables verification of thesecurity state of the shared keys, and safety can be secured bynotification or the like in a case where the security state isunsuitable. Performing the shared key security state inspection in astopped state such as at the time of ACC-ON and ACC-OFF, avoidingincreased processing load on the ECUs and increased traffic on the bus200 while the vehicle is driving, is useful.

3.5 Modification of Third Embodiment

The onboard network system including a master ECU 31400 (key managingdevice) which is a partial modification of the above-described masterECU 30400 will be described below. The master ECU 31400 is basically thesame as the master ECU 30400, but the method of confirming the order ofresponses that the ECUs return after having transmitted the survivalconfirmation frame as a request differs. That is to say, the master ECU31400 has a function of confirming the order of responses (serial IDnotification frames) received from the ECUs by communication with aserver that is external from the onboard network system (outside of thevehicle), This server is a computer that manages information indicatingthe order of CAN-IDs in the serial ID notification frames transmitted asresponses to the survival confirmation frame.

3.6 Configuration of Master ECU 31400

FIG. 29 is a configuration diagram of the master ECU 31400. The masterECU 31400 includes the frame transmission/reception unit 401, the frameanalyzing unit 402, the reception ID judging unit 403, the reception IDlist storing unit 404, the MAC processing unit 406, the counter storingunit 407, the session key list storing unit 408, the encryptionprocessing unit 409, the shared key list storing unit 20410, the sessionkey generating unit 411, the frame generating unit 412, and a servercommunication unit 31412. These components are functional components,and the functions thereof are realized by a communication circuit in themaster ECU 31400, a processor or digital circuit of the like thatexecutes the program stored in the memory, and so forth. Note that thecomponents of the master ECU 31400 that are the same as the componentsof the master ECU 400 and master ECU 20400 (see FIGS. 3 and 20) aredenoted by the same reference numerals, and description will be omittedas appropriate.

In a case of having succeeded in verification, as the result ofverifying a MAC of a data frame at the MAC processing unit 406, theframe analyzing unit 402 notifies the server communication unit 31412 ofthe CAN-ID of the data frame and the value of the data field.

The server communication unit 31412 has a function of communicating withan external server wirelessly. The server communication unit 31412correlates the CAN-IDs of all data frames received from the frameanalyzing unit 402 and the values of the data fields, notifies theserver, and receives determination results from the server. In a casewhere an error occurs as a result of determination, the driver isnotified by displaying the content of the error on the display device,for example. In a case where the determination results at the serverregarding the order of serial ID notification frames transmitted fromthe ECUs as responses to the survival confirmation frame as a requestare an error, the master ECU 31400 can display an error, record in alog, or the like. Also, in a case of an error, the master ECU 31400 cankeep transmission of session keys to the ECUs from being performed.

Note that the external server is a computer communicable with the masterECU 31400, and has a function of, in a case of having received from themaster ECU 30400 a series of CAN-IDs and values indicating serial IDsthat are data field values, regarding serial ID notification frames,recording and managing the CAN-IDs and serial IDs predetermined to eachtransmission source ECU, in the order of serial ID reception, andcomparing with the contents serially received and recorded the previoustime. In a case where the comparison shows that the serial IDnotification frames serially received match the contents recorded theprevious time (i.e., a case where the order of CAN-IDs matches, and alsothe combination with serial IDs also matches), a determination result ofnormal is transmitted to the master ECU 31400, and if not matching, anerror is transmitted.

3.7 Shared Key Verification Sequence

The following is a description of operations of the master ECU 31400inspecting the security state relating to shared keys, with reference toFIG. 30. FIG. 30 illustrates an example of a shared key verificationsequence by the master ECU 31400, the ECU 20100 a, the ECU 20100 b, theECU 20100 c, and the ECU 20100 d. Note that this shared key verificationsequence is executed when the vehicle in which is installed the onboardnetwork system is in a particular state (e.g., a stopped state beforedriving), for example. As for a specific example, this is executedimmediately after entering the accessory-on (ACC-ON) state andimmediately after entering the accessory-off (ACC-OFF) state. Note thatprocessing (steps) in FIG. 30 that are the same as those shown in FIG.28 are denoted by the same reference numerals, and description will beomitted here.

In step S3102, serial ID notification frames transmitted by the ECU20100 a, ECU 20100 b, ECU 20100 c, and ECU 20100 d as responses to thesurvival confirmation frame sequentially appear on the bus 200.

The master ECU 31400 consecutively transmits to the server the sets ofCAN-IDs of the serial ID notification frames consecutively andsequentially appearing on the bus 200 and the values included in theserial ID notification frames. Whether or not the security state of theshared keys is suitable is inspected, by whether or not thedetermination results returned from the server are normal (step S3203).In a case where the determination results from the server are an error,i.e., the order of responses from the ECUs as to the survivalconfirmation frame does not match the order of responses as to thesurvival confirmation frame the previous time, or the contents of theresponses (serial IDs) do not match the previous time, and accordinglythe security state of the shared key is in appropriate, the master ECU31400 notifies the driver by display of information indicating an error(information indicating that there is an unauthorized ECU, etc.) on thedisplay device (step S3204).

3.8 Advantages of Modification of Third Embodiment

In the onboard network system according to the modification of the thirdembodiment, the master ECU 31400 communicates with an external server ina case where the vehicle is in a particular state such as a stoppedstate or the like, and causes the server to determine whether the orderof frames that the ECUs transmit is suitable, thereby verifying whetheror not the security state of the shared keys is appropriate. In a casewhere the configuration of the onboard network system has been changed,the order of frames transmitted by the ECUs changes as compared tobefore, so this is determined to be an error by the server. In a casewhere the security state is inappropriate (a case where determination ofan error has been made), safety can be secured by notification and thelike. The external server can collect information of the serial IDs ofthe ECUs from the master ECU 31400 in the onboard network systeminstalled in multiple vehicles and confirm the integrity, so thesecurity state of the shared keys can be inspected more appropriately.

Other Embodiments

The first through third embodiments have been described above asexamples of the technology according to the present disclosure. However,the technology according to the present disclosure is not restricted tothis, and embodiments where modifications, substitutions, addition,omission, and so forth have been performed as appropriate are alsoapplicable. For example, the following modifications are also includedas an embodiment.

(1) Although an example has been described in the above embodimentswhere frames are periodically transmitted by the ECUs, an arrangementmay be made where frames are transmitted as an event to notify a statechange. For example, an arrangement may be made where a frame istransmitted only in a case where the door open/closed state changes,instead of periodically transmitting the door open/closed state.Further, an arrangement may be made where the ECU transmits frames bothperiodically and when a state change has occurred.

(2) Although an example has been described in the above embodimentswhere a MAC is generated (calculated) by computation based on the CAN-IDand data value and counter value, it is sufficient to generate a MACreflecting the content of a part of the data frame (i.e., based onpartial content), and the MAC may be generated from the data valuealone. Alternatively, the MAC may be generated from the counter valuealone. It is sufficient for the MAC verification method at the ECUreceiving the data frame to correspond to the method of attaching theMAC to the data frame that the ECU transmitting the data frame uses. Thedata frame to which the MAC is attached may include, in the data field,part of all of counter values, besides the data value and MAC. The sizeof the MAC included in the frame is not restricted to four bytes, andmay be varied sizes from one CAN-ID to another. The MAC may be dividedinto a plurality, and the divided MAC included in frames, so that theMAC is transmitted spanning multiple frames. The size of the countervalue also is not restricted to one byte.

(3) Although an example has been described in the above embodimentswhere the counter value is incremented with each transmission, anarrangement may be made where the counter value is automaticallyincremented according to the point-in-time. Alternatively, thepoint-in-time itself may be used instead of the counter. Computation ofthe counter value is not restricted to incrementing (increasing by 1).This may be increased by 2 or more, and instead of counting up byincrementing, this may be counting down by decrement. Computation of thecounter value may be performed by bit-shift, or may be computation wherean output value, identified based on a predetermined algorithm takingthe computation result of the previous time as the input value, is takenas the computation results.

(4) Although an example has been described in the above embodimentswhere the data frame in the CAN protocol is described in a standard IDformat, this may be an extended ID format. In a case of the extended IDformat, the CAN-ID is expressed as a total of 29 bits of the base ID atthe ID position in the standard ID format, and the extended ID.

(5) Although an example has been described in the above embodimentswhere the MAC calculation algorithm is AES-CMAC, this may be CipherBlock Chaining Mess age Authentication Code (CBC-MAC) or Hash-basedMessage Authentication Code (HMAC). The padding used in MAC calculationmay be zero padding, ISO10126, PKCS #1, PKCS #5. PKCS #7, or nay otherpadding method where the block data size is necessary for calculation. Amethod for changing the block size to four bytes or the like may usepadding at the any of the start, end or middle. Data used for MACcalculation does not have to be consecutive data (e.g., four byte worthof consecutive data), and may be data that has been collected one bit ata time following a particular rule and linked.

(6) Although an example has been described in the above embodimentswhere the session key is four bytes (see FIG. 6), the size of thesession key is not restricted to this, and may by eight bytes or thelike. The session key may be transmitted spanning multiple frames, ifthe session key is of a size that cannot be stored in one frame. Notethat transmission of the session key ma be realized by any method aslong as the transmitting side and the receiving side can store the samesession key. Besides being realized by transmitting an encrypted sessionkey, this may be realized by transmitting information necessary togenerate a session key.

(7) Although an example has been described in the above embodimentswhere particular states (immediately after ACC-ON, immediately afterACC-OFF, etc.) are given as the particular state for inspecting thesecurity state of the shared key (shared key verification sequence),other particular states may be used. For example, this may beimmediately after the engine is started or immediately after a statewhere the engine is off. Alternatively, a state where the vehicle is notdriving may be the particular state for inspecting the security state ofthe shared key (confirmation, etc.), such as immediately after ACC-ON,immediately after ACC-OFF, a state where the engine is off, and soforth. Performing the inspection of the security state of the shared keyonly in a particular state where the vehicle is not driving is usefulfrom the point of preventing increase in the load on the ECUs. Also,“fueling” may be determined according to whether the fuel cap is open orclosed, and start the shared key verification sequence while fueling. Ina case of an electric vehicle, “charging” may be determined by detectingthat a charging plug has been connected, and start the shared keyverification sequence while charging. Further, switching between“parked”, “stopped”, and “driving” and so forth may be distinguishedbased on the gearshift or the like of the vehicle, and the shared keyverification sequence may be started while parked, for example, or“high-speed driving” and “low-speed driving” may be distinguished andthe shared key verification sequence may be started during low-speeddriving. The execution timing of the shared key verification sequence inthe modification of the third embodiment is not restricted toimmediately after ACC-ON and immediately after ACC-OFF, but rather maybe only immediately after ACC-ON or only immediately after ACC-OFF, ormay be at another timing (immediately after starting the engine, etc.).

(8) One shared key shown in the above embodiments may be stored for eachECU, or in a case where the ECU performs frame transmission usingmultiple CAN-IDs, one may be stored for each CAN-ID. The increments ofthe master ECU and one or multiple other ECUs each storing shared keysmay be optionally decided in the onboard network system.

(9) Although an example has been described in the above embodimentswhere one counter (transmission counter value and reception countervalue) is stored for each CAN-ID, this may be one for each ECU (i.e.,each group of one or more CAN-IDs). Alternatively, a common countervalue may be used for all frames flowing over the same bus.

(10) Transmission of information (frame) as a response to the survivalconfirmation frame in the above-described third embodiment does notnecessarily have to be transmission of a serial ID notification frame,and a serial ID does not necessarily have to be included in the datafield. Besides the method of confirming matching with the order from theprevious time as a method to confirm (inspect) the transmission order offrames, as responses from the ECUs as to the survival confirmationframe, a method may be used to confirm matching with the order in a listrecording the order beforehand.

(11) The shared keys shared between the master ECU (key managing device)and other multiple ECUs (keys shared before transmission of sessionkeys) shown in the above-described embodiments may be shared keys in ashared key encryption system (secret keys), or alternatively may be akey pair (public key and secret key) in a public key encryption system.That is to say, it is sufficient for a first-type electronic controlunit (master ECU) serving as the key managing device, and one or moresecond-type electronic control units (ECUs other than the master ECU)mutually storing sharked keys that are the same or are a key pair. Inaddition to the respective devices (first-type ECU and second-type ECU)each storing the same key, an arrangement in which each device(first-type ECU and second-type ECU) stores the same key pair of publickey and secret key is also referred to as sharing a shared key. As oneexample, each ECU in the onboard network system may have individualsecret keys, the master ECU have public keys corresponding to the secretkeys of the ECUs, with the master ECU encrypting session keys using thepublic keys and transmitting to the ECUs.

(12) Although an example has been described in the above embodimentswhere the ECU that receives the data frames being exchanged among theECUs performs verification of the MACs thereof, an arrangement may bemade where a MAC verification ECU exists in the onboard network systemto verify the MACs given to all data frames by itself. This MACverification ECU may acquire and store the MAC generating keys andcounter values corresponding to all CAN-IDs. In a case where the MACverification ECU determines that there is an error as the result of MACverification by this MAC verification ECU, an error frame may betransmitted to prevent reception at other ECUs.

(13) Although an example has been described in the above first andsecond embodiments where the security state of the validity and so forthof the shared keys that all ECUs store is inspected (verified) all atonce, inspection (verification) may be individually performed at eachECU. Depending on the state of the vehicle, inspection (verification)processing of particular types of ECUs may be skipped. For example, in astate while the vehicle is driving, inspection (verification) processing(e.g., transmission of expiration date notification frames, etc.)relating to driving system ECUs related to driving (e.g., the ECU 100 arelated to the engine, etc.) may be skipped.

(14) Although the master ECU and other ECUs in the above embodimentshave been described as having digital circuits such as a processor,memory, and so forth, analog circuits, communication circuits, and soforth, the ECUs may include other hardware component such as a harddisk, display, keyboard, mouse, and so forth. The functions thereof maybe realized by dedicated hardware (digital circuits and so forth)instead of realizing the functions by software by a control programstored in memory being executed by the processor.

(15) Part or all of the components of which the above-described devicesare configured may be configured as one system Large Scale Integration(LSI). A system LSI is a super-multifunctional LSI fabricated withmultiple components integrated on a single chip, and specifically is acomputer system configured including a microprocessor, ROM, RAM, and soforth. The RAM stores the computer program. The system LSI achieves itsfunctions by the microprocessor operating according to the computerprogram. The components of which the above-described devices areconfigured may each be independently formed as a single chip, or part orall may be included in a single chip. While a system LSI has beenmentioned, there are different names according to the degree ofintegration, such as IC, LSI, super LSI, and ultra LSI. The way in whichthe integrated circuit is formed is not restricted to LSIs, and may berealized by dedicated circuits or general-purpose processors. A FieldProgrammable Gate Array (FPGA) capable of being programmed aftermanufacturing the LSI, or a reconfigurable processor of which theconnections and settings of circuit cells within the LSI can bereconfigured, may be used. Moreover, in the event of the advent of anintegrated circuit technology which would replace LSIs by advance ofsemiconductor technology or a separate technology derived therefrom,such a technology may be used for integration of the functional blocks,as a matter of course. Application of biotechnology is a possibility.

(16) Part or all of the components of which the above-described devicesare configured may be configured as an integrated circuit (IC) carddetachably mountable to each device, or a standalone module. The IC cardor standalone module is a computer system configured including amicroprocessor, ROM, RAM, and so forth. The IC card or standalone modulemay include the above-described super-multifunctional LSI. The IC cardor standalone module achieves its functions by the microprocessoroperating according to the computer program. The IC card or standalonemodule may be tamper-resistant.

(17) The present disclosure may in one form be a key management methodsuch as the shared key verification sequence described above, may be acomputer program which realizes these methods by a computer, or may bedigital signals made up of the computer program. The present disclosuremay in one form be the computer program or the digital signals recordedin a computer-readable recording medium, such as for example, a flexibledisk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray (aregistered trademark) Disc), semiconductor memory, or the like. Thepresent disclosure may also be the digital signals recorded in theserecording mediums. The present disclosure may be an arrangement wherethe computer program or the digital signals are transmitted over anelectric communication line, wireless or cable communication line, anetwork of which the Internet is representative, data broadcasting, orthe like. The present disclosure may be a computer system having amicroprocessor and memory, where the memory stores the computer program,and the microprocessor operates according to the computer program. Thismay also be carried out by another independent computer system, by theprogram or digital signals being recorded in the recording medium andbeing transported, or by the program or digital signals beingtransferred over the network or the like.

(18) The forms realized by optionally combining the components andfunctions exemplified in the above-described embodiments and theabove-described modifications are also included in the scope of thepresent disclosure.

The present disclosure is applicable to management of keys used in ECUsin an onboard network system.

What is claimed is:
 1. A key management method in a key managementdevice serving as an electronic control unit (ECU) in an onboard networksystem having a plurality of electronic control units (ECUs) thatperform communication by frames via a network, the method comprising:storing, in a first-type electronic control unit out of the plurality ofelectronic control units, a shared key to be mutually shared with one ormore second-type electronic control units other than the first-typeelectronic control unit, the shared key also being stored in the one ormore second-type electronic control units other than the first-typeelectronic control unit; executing encryption processing regarding aframe transmitted or received via the network, based on the shared key;and executing, by the first-type electronic control unit, inspection ofa security state of the shared key stored by the second-type electroniccontrol units in a case where a vehicle in which the onboard networksystem is installed is in at least one particular state, wherein the atleast one particular state includes at least one of the followingparticular states, (a) the vehicle is not driving and is an accessory-onstate, (b) a fuel cap of the vehicle is open, and the vehicle is notdriving and is fueling, (c) the vehicle is parked, which is indicated bythe gearshift, (d) the vehicle is in a stopped state before driving,which is indicated by the gearshift, and (e) a charging plug isconnected to the vehicle, and the vehicle is electrically charging. 2.The key management method according to claim 1, wherein the inspectionis an inspection relating to an expiration date of the shared key. 3.The key management method according to claim 1, wherein the inspectionis an inspection relating to a serial ID of the second-type electroniccontrol unit that stores the shared key.
 4. The key management methodaccording to claim 1, wherein, in a case where the plurality ofelectronic control units includes a plurality of the second-typeelectronic control units, the inspection is an inspection relating to atransmission order of frames at the plurality of second-type electroniccontrol units.
 5. The key management method according to claim 4,wherein the first-type electronic control unit transmits a frameindicating a predetermined request and thereafter sequentially receivesframes from the plurality of second-type electronic control units, andbased on the IDs of the frames, performs the inspection bydistinguishing whether or not the IDs have been received in an orderthat a predetermined order list indicates.
 6. The key management methodaccording to claim 1, wherein the first-type electronic control unitexecutes the inspection only in a case of the particular state.
 7. Thekey management method according to claim 1, wherein the first-typeelectronic control unit executes the inspection by communication with aserver located externally from the vehicle.
 8. The key management methodaccording to claim 1, wherein the plurality of electronic control unitsperform communication by frames via the network, following a ControllerArea Network protocol.
 9. An onboard network system having a pluralityof electronic control units (ECUs) that perform communication by framesvia a network, the system comprising: a first-type electronic controlunit, out of the plurality of electronic control units, configured tostore a shared key to be mutually shared with one or more second-typeelectronic control units other than the first-type electronic controlunit, the shared key also being stored in the one or more second-typeelectronic control units other than the first-type electronic controlunit; and each of the second-type electronic control units configured toexecute encryption processing regarding a frame transmitted or receivedvia the network, based on the shared key, wherein the first-typeelectronic control unit executes inspection of a security state of theshared key stored by the second-type electronic control units in a casewhere a vehicle in which itself is installed is in at least oneparticular state, (a) the vehicle is not driving and is an accessory-onstate, (b) a fuel cap of the vehicle is open, and the vehicle is notdriving and is fueling, (c) the vehicle is parked, which is indicated bythe gearshift, (d) the vehicle is in a stopped state before driving,which is indicated by the gearshift, and (e) a charging plug isconnected to the vehicle, and the vehicle is electrically charging. 10.A key management device serving as an electronic control unit (ECU) inan onboard network system having a plurality of electronic control units(ECUs) that perform communication by frames via a network, the devicecomprising: a processor; and a memory having a computer program storedthereon, the computer program causing the processor to executeoperations including storing a shared key to be mutually shared with oneor more electronic control units other than itself out of the pluralityof electronic control units, the shared key also being stored in the oneor more second-type electronic control units other than the first-typeelectronic control unit, and inspecting of a security state of theshared key stored by the electronic control units other than itself in acase where a vehicle in which itself is installed is in at least oneparticular state, (a) the vehicle is not driving and is an accessory-onstate, (b) a fuel cap of the vehicle is open, and the vehicle is notdriving and is fueling, (c) the vehicle is parked, which is indicated bythe gearshift, (d) the vehicle is in a stopped state before driving,which is indicated by the gearshift, and (e) a charging plug isconnected to the vehicle, and the vehicle is electrically charging.